Remarks 

This Response is considered fully responsive to the Non-Final Office Action mailed April 
7, 2009. In this Response, no claims have been amended, added or cancelled. Therefore, claims 
1-7, 9, 14-17, and 30-46 remain pending in the Application. Reexamination and reconsideration 
are requested. 



Rejections Under 35 U.S.C. §1 03(a) 

§ 103(a) Rejection I: 

Claims 1, 2, 4, 14, 16, 17, 30, 31, 34, 35, 38, 39, 42-46 were rejected under 35 U.S.C. 
§ 103(a) as purportedly being unpatentable over Rajahalme, WO 2002/071720 ("Rajahalme"), in 
view of Request For Comments 2461 ("RFC"), in further view of Lamberton et al, U.S. Patent 
No. 6,779,017 ("Lamberton"), and in further view of Yates et al., U.S. Patent No. 6,167,438 
("Yates"). Applicant respectfully traverses the rejection for at least the following reasons. 

Applicant maintains that the Rajahalme, RFC, Lamberton and Yates references are not properly 
combinable. Nevertheless, Applicant contends that Rajahalme, RFC , Lamberton and Yates, taken alone 
or in combination, neither teach nor suggest all the limitations of independent claim 1. 



Independent claim 1 reads as follows: 

1 . A method of content delivery in a network, comprising: 

associating each of a plurality of devices in a Domain Name 
System (DNS) with one of a plurality of cache server systems located in 
the network and maintaining on each of the cache server systems content 
stored on an origin server; 

assigning to the DNS devices a common address; 

advertising, by each of the DNS devices, the common address 
within the network; 

monitoring one or more load characteristics of one or more of the 
cache server systems in the network; 

determining if one or more of the load characteristics exceeds a 
predefined overload metric; and 

discontinuing advertising of the common address by each DNS 
device associated with a cache server system determined to have a 
load characteristic that exceeds the predefined overload metric. 

(emphasis added) 
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The "RFC" Reference 

In the April 7, 2009 Office Action, the Examiner correctly concedes that Raiahalme , 
Lamberton and Yates do not teach the claim 1 limitations of: i) advertising, by each of the DNS 
devices, the common address within the network, and ii) discontinuing advertising of the 
common address by each DNS device associated with a cache server system determined to have 
a load characteristic that exceeds the predefined overload metric. However, Applicant 
respectfully disagrees with the Examiner's contention that the RFC reference teaches these 
limitations. 

In general, the RFC reference states that, "IPv6 nodes on the same link use Neighbor 
Discovery to discover each other's presence, to determine each other's link- layer addresses, to 
find routers and to maintain reachability information about the paths to active neighbors." RFC , 
Abstract. In this manner, network nodes can determine the presence of other nodes in a network 
through the use of Neighbor Solicitation and Neighbor Advertisement messages. In contrast, the 
method recited in claim 1 generally relates to load-balancing among cache servers. This can be 
accomplished, for example, by providing a common address of a DNS (associated with a 
plurality of cache servers) to other nodes in a network. Unlike the Neighbor Discovery protocol, 
the common address of claim 1 is not being advertised so that the DNS device(s) can discover 
other network nodes and maintain reachability information. 

Furthermore, the Examiner incorrectly equates Neighbor Unreachability Detection 
with the claim 1 limitation of "discontinuing advertising a common address." Neighbor 
Unreachability Detection enables a "node [to] actively track the reachability 'state' for the 
neighbors to which it is sending packets." RFC , § 7.3.1. For instance, "a neighbor is considered 
reachable if the node has recently received a confirmation that packets sent recently to the 
neighbor were received by its IP layer. Positive confirmation [is indicated by] . . . receipt of a 
Neighbor Advertisement message that is a response to a Neighbor Solicitation message." RFC , § 
7.3.1. As such, the Neighbor Unreachability Detection procedure does not cause Neighbor 
Advertisement messages to be discontinued. In fact, Neighbor Unreachability Detection 
encourages the transmission of Neighbor Advertisement messages (i.e., to be sent in response to 
the Neighbor Solicitation messages that initiate the Neighbor Unreachability Detection 
procedure, per RFC , § 7.3.1). Thus, at least in this respect, the RFC reference teaches away from 
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the claim 1 operation of "discontinuing advertising the common address." 

The following passage in the RFC reference pertains to node behavior during Neighbor 
Unreachability Detection: 

RFC § 7.3.3: Node Behavior 

While in the PROBE state, a node retransmits Neighbor Solicitation 
messages every RetransTimer milliseconds until reachability confirmation 
is obtained. Probes are retransmitted even if no additional packets are sent 
to the neighbor. If no response is received after waiting RetransTimer 
milliseconds after sending the MAX UNICAST SOLICIT solicitations, 
retransmissions cease and the entry SHOULD be deleted. Subsequent 
traffic to that neighbor will recreate the entry and performs address 
resolution again. Note that all Neighbor Solicitations are rate-limited on a 
per-neighbor basis. A node MUST NOT send Neighbor Solicitations to 
the same neighbor more frequently than once every RetransTimer 
milliseconds. 

(emphasis added) 

Note that it is the Neighbor Solicitation messages and not the Neighbor Advertisement 
messages that are rate-limited. As its name suggests, a Neighbor Solicitation message is a 
request for an address advertisement and not the address advertisement itself. Furthermore, it is 
incorrect to infer that limiting the transmission ofNeighbor Solicitation messages indirectly 
causes the transmission ofNeighbor Advertisement messages to be limited. According to the 
RFC reference, the reason Neighbor Solicitation messages are no longer sent to a given node is 
because no Neighbor Advertisement messages were ever received from the given node. In other 
words, the transmission ofNeighbor Advertisement messages cannot be discontinued if they 
were never being transmitted in the first place. Thus, neither the Neighbor Solicitation nor the 
Neighbor Advertisement behaviors described in the RFC reference teach or suggest the claim 1 
operation of "discontinuing advertising a common address." 

The "Lamberton" Reference 

The Examiner also concedes that the Yates, Rajahalme and RFC references do not teach 
or suggest "determining if one or more of the load characteristics exceeds a predefined threshold; 
and discontinuing device associated with a server system determined to have a load 
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characteristic that exceeds the predefined overload metric." However, the Examiner argues that 
Lamberton teaches these limitations. Although Applicant agrees that the Yates , Rajahalme, and 
the RFC references do not teach or suggest these limitations, Applicant was unable to find the 
"discontinuing device associated with a server system. . ." limitation in claim 1 . Applicant 
assumes that the Examiner is referring to the operation of "discontinuing advertising of the 
common address by each DNS device associated with a cache server system determined to have 
a load characteristic that exceeds the predefined overload metric" recited in claim 1. (emphasis 
added) Presuming this to be the case, Applicant contends that Lamberton does not teach or 
suggest these limitations for at least the following reasons. 

The Examiner cites the following passage in Lamberton to reject claim 1: 

The metric used to decide which server is to be selected at a given 
instant depends on the design of the load balancer which is assumed to 
collect from all the servers, at regular intervals, performance information 
regarding their level of activity. In broad general terms, it can be said that 
the least busy of the servers is selected in an attempt to indeed reach the 
goal of balancing the workload equally over all the servers. Lamberton. 
col. 6, lines 22-30. 

The Examiner attempts to draw a comparison between the "least busy server" technique 
of Lamberton and the 'overload' metric recited in claim 1. This comparison is incorrect. The 
load-balancing technique used in Lamberton does not determine whether a server system is too 
busy to service new requests (e.g., by using an overload metric). Instead, the Lamberton 
technique selects a "least busy server" by comparing the relative activity levels among the 
servers. Note that the non-selected (or non-"least busy") servers in Lamberton may still be 
capable of handling new requests even though these servers were not deemed to be the least 
active. As such, the Lamberton load-balancing technique is incapable of determining whether a 
particular server (or cluster of servers) is overloaded and should not have any new requests 
routed thereto. 

Furthermore, Applicant believes that Rajahalme and Yates fail to overcome at least the 
deficiencies discussed above with respect to the RFC and Lamberton references. 

For at least these reasons, claim 1 is patentable over the cited references and is in a 
condition for allowance. As claims 2-7, 9, 14-17, 42, and 43 depend from allowable claim 1, 
these claims are also in a condition for allowance. 
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Additionally, as independent claims 30, 34, 38, and 41 contain the same or similar 
limitations as allowable claim 1 , these claims are also patentable over the cited references for at 
least the reasons discussed above and are in a condition for allowance. As claims 31-33, 35-37, 
39-40, and 44-46 depend from allowable claims 30, 34, 38, and 30, respectively, these claims are 
also in a condition for allowance. 

§ 103(a) Rejection II: 

The Examiner has rejected claims 3, 5-7, 9, 15, 32, 33, 36, 37, 40 and 41 under 35 U.S.C. 
§ 103(a) as being unpatentable over Rajahalme in view of RFC in view of Lamberton in view of 
Yates in further view of Garcia-Lunes-Aceves, U. S. Patent Application No. 2006/0271705 
("Garcia"). The Applicant respectfully traverses the rejection for at least the following reasons. 

Claims 3, 5-7, 9 and 15 depend from allowable claim 1 and are believed to be patentable 
for at least the same reasons as discussed above with respect to claim 1. Similarly, claims 32-33, 
36-37, and 40 depend from allowable claims 30, 34, and 38, respectively, and are believed to be 
patentable for at least the same reasons as discussed above with respect to claim 1 . Independent 
claim 41 is also believed to be patentable for at least the same reasons as discussed above with 
respect to claim 1 . Further, Applicant believes that Garcia fails to overcome at least the 
deficiencies discussed above with respect to Rajahalme , RFC , Lamberton and Yates . 
Accordingly, Applicant respectfully requests that the Examiner reconsider and withdraw the 
rejection allow claims 3, 5-7, 9, 15, 32, 33, 36, 37, 40 and 41. 

Extension of Time 

Applicant hereby petitions for a two-month extension of time and is electronically 
submitting the required fee with this Amendment and Response. Applicant believes no other 
fees or petitions are due with this filing. However, should any such fees or petitions be required, 
please consider this a request therefor and authorization to charge Deposit Account No. 50-3199 
as necessary. 
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Conclusion 

Claims 1-7, 9, 14-17, and 30-46 are currently pending in the application. Applicant 
believes that claims 1-7, 9, 14-17, and 30-46 arc in a condition for allowance. Applicant 
therefore requests that a timely Notice of Allowance be issued in this case. 

The Commissioner is authorized to deduct any additional fees from or credit any 
overpayment to the undersigned's account no. 503199. 

If the Examiner should require any additional information or amendment, please contact 
the undersigned attorney. If the Examiner believes any issues could be resolved via a telephone 
interview, the Examiner is invited to contact the undersigned at the telephone number listed 
below. 

Respectfully submitted, 

/Thomas J. Osborne, Jr./ 

Date: September 8, 2009 

Thomas J. Osborne, Jr. 
Registration No. 39,796 
USPTO Customer No. 83579 

Hensley Kim & Holzer, LLC 
1660 Lincoln Street, Suite 3000 
Denver, Colorado 80264 
Tel: 720-377-0770 
Fax: 720-377-0777 

TJO/jw 
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